-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add feature to ignore git commits by id #327
Add feature to ignore git commits by id #327
Conversation
I also rebased it onto master just now |
@philippn : thanks a lot!
@dbwiddis @hazendaz : PR looks good to me as-is but please add your review if you can since you contribute a lot you might have your word on it too ;-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments inline.
- Also you should add a test to
GitLookupTest
to verify that it works.
license-maven-plugin-git/src/main/java/com/mycila/maven/plugin/license/git/GitLookup.java
Outdated
Show resolved
Hide resolved
license-maven-plugin-git/src/main/java/com/mycila/maven/plugin/license/git/GitLookup.java
Outdated
Show resolved
Hide resolved
...aven-plugin-git/src/main/java/com/mycila/maven/plugin/license/git/GitPropertiesProvider.java
Outdated
Show resolved
Hide resolved
license-maven-plugin-git/src/main/java/com/mycila/maven/plugin/license/git/GitLookup.java
Outdated
Show resolved
Hide resolved
license-maven-plugin-git/src/main/java/com/mycila/maven/plugin/license/git/GitLookup.java
Outdated
Show resolved
Hide resolved
...aven-plugin-git/src/main/java/com/mycila/maven/plugin/license/git/GitPropertiesProvider.java
Outdated
Show resolved
Hide resolved
license-maven-plugin-git/src/test/java/com/mycila/maven/plugin/license/git/GitLookupTest.java
Outdated
Show resolved
Hide resolved
license-maven-plugin-git/src/main/java/com/mycila/maven/plugin/license/git/GitLookup.java
Show resolved
Hide resolved
Set<String> commitsToIgnore = Collections.emptySet(); | ||
if (commitsToIgnoreString != null) { | ||
commitsToIgnoreString = commitsToIgnoreString.trim(); | ||
commitsToIgnore = Arrays.stream(commitsToIgnoreString.split(",")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One other suggestion. Splitting on a comma forces users into a long one-line string here. You could split on a non-hex digit, e.g., [^0-9a-fA-F]+
(and also filter out empty strings after the split) which would allow flexibility such as listing commits on newlines like:
<license.git.commitsToIgnore>
6eb93dcfc014bfd3980c1f1c43f10fd59422107e,
ad1e59a6afc5a1a7edbdc8bcf949bb2f8682f074,
70403fdbc424e5d2045389e685f9bb9bd696d5cd
</license.git.commitsToIgnore>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, the reason I'm making this suggestion is that I really think this is a cool feature and I'm eager to use it, and somewhat biased by how I want to use it. ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked into this, I'm a bit vary to use lots of regex magic here as it is not easily testable. It would probably make sense to create a test for GitPropertiesProvider
, but that would require factoring out the instantiation of the GitLookup
into some kind of factory.
So for the time being, I added a trim
operation to the streaming expression, that should basically result in the same behaviour. So technically, I believe your example above should work :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked into this, I'm a bit vary to use lots of regex magic here as it is not easily testable.
Fair enough. I hit regex101 to play around with my proposal and it took a few iterations to confirm what I expected; and the added complexity of producing empty strings that you then have to filter was undesirable. I like your trim()
solution and it (should) work with my use case.
It would probably make sense to create a test for
GitPropertiesProvider
, but that would require factoring out the instantiation of theGitLookup
into some kind of factory.
Yeah. I'm not fond of the existing lazy initialization but haven't had time to think of a better way to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would probably make sense to create a test for
GitPropertiesProvider
, but that would require factoring out the instantiation of theGitLookup
into some kind of factory.Yeah. I'm not fond of the existing lazy initialization but haven't had time to think of a better way to do it.
So that is fixed in #339
I'm a bit overwhelmed by all this feedback, please bear with me :-) So in the order of the points being mentioned:
Regarding the concrete things pointed out by @dbwiddis I will comment on each individually. Thanks for your feedback, it's much appreciated! |
Speaking for project maintainers in general, we are thrilled with contributions from the community and we will happily bear with you as needed. Thanks for contributing and being so gracious with the feedback. This LGTM at this point. Not sure what's going on with the tests, but if @mathieucarbou wants to merge this push out an rc3 that I can fiddle with real-life testing on my own project I'm happy to do that! |
@hazendaz JDK 17 / 18 tests are failing with "Not executing Javadoc as the project is not a Java classpath-capable package" ... hope that's something you're already working on. Do we need to rebase this PR? |
Had not seen that yet but will take a look at that one. Thanks. |
@dbwiddis javadoc may be unrelated issue. The issue that jump sout at failure is test coverage drops down by 1% on 17/18. Not sure exactly why but I had the same issue when setting jacoco up there. Typically I go with more strict enforcement of coverage but in this case wanted to go with the closest to IDE coverage stats in Eclipse. So to fix that @philippn, its easy go to the 2 submodule poms (license-maven-plugin and license-maven-plugin-git. Just drop the jacoco.minimum coverage number by 1% in both. That should get it to green here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please wait for #339 to be merged first and rebase onto after.
@dbwiddis : your merge commit looks weird ;-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR has to be rebased on top of master and conflicts solved as part of the rebase.
Don't ask why there are two merge commits. But I've fixed conflicts 4 times now and I think it's correct now. 😁 |
I'll check. Not normal... gît fetch upstream && gît rebase -i upstream/master then fix conflits during rebase, there should be one commit and no merge commit, then force push. |
Yeah, I know how it's supposed to work. Between the GitHub CLI and my IDE things didn't work out well the first time. I successfully merged the second go around but then ended up unable to push back to this branch, so I cherry-picked the merge commit onto this branch and it seemed to work, with the exception of showing two commits. |
That is normal that you were not able to push back because rebasing changes the history and commit ID to place it on top of master. You have to force the puah, which will rewrite the branch history for this commit and GitHub will show your icon next to @philippn 's icon |
Well, in any case, the two commits are identical and the result of all this is correctly working code that can be merged. If someone wants to put in the work to back those commits out and start afresh, feel free. Having done the same changes 4 times, I'm done. 😁 |
Well, that worked just fine at home on my mac. 😏 |
Still not rebased on master if we look at the graph: https://github.com/mathieucarbou/license-maven-plugin/network |
Solved. FYI ❯ git fetch --all
❯ git remote-add-gh philippn # a custom macro I did to add a fork and fetch it
❯ git checkout philippn/features/ignore-commits -b ignore-commits
❯ git rebase upstream/master
❯ git push -f philippn HEAD:features/ignore-commits When doing changes for maven / build / infra stuff, I am less "picky", but when merging code related to enhancement and features I want the commits to be rebased on master and merged with a merge commit to maintain a clean history. |
license-maven-plugin-git/src/main/java/com/mycila/maven/plugin/license/git/GitLookup.java
Outdated
Show resolved
Hide resolved
… and cleanup property parsing
Hey @mathieucarbou ,
here is the PR, thanks for your consideration.
Kind regards,
Philipp